CCA#3-Attachment B 


CHANGE ORDER NO. 26 

This agreed Change Order to Contract #229944 (Change Order) is entered into by and 
between ERG Transit Systems (USA) Inc, a California corporation and wholly owned 
subsidiary of ERG Limited, an Australian corporation, (hereinafter referred to as the 
"Contractor") and each of the following seven public transportation agencies (hereinafter 
referred to individually as an "Agency" or collectively as the "Agencies"): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area ("Pierce Transit") 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett ("Everett") 

7. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 

Recitals 


A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract 
#229944 ("Contract") to implement a Regional Fare Coordination System ("RFC System") to 
establish a common fare system utilizing smart card technology. The Contractor is responsible 
for the development, implementation, operation and maintenance of the RFC System as 
specified in the Contract. 

B. This Change Order #26 is attached to, and adopted by, the Agencies and the 
Contractor as part of Contract Change Agreement #3. 

I 

Agreement 

The Agencies and the Contractor hereby agree to amend the Contract as follows: 


1.0 Change to Section 6.11-11.4.3.2 

Sec. 11.4.3.2 is amended to read as follows: 
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6.11-11.4.3.2 RFCS Test Bed 


a. The Contractor shall provide a test-bed located in the Puget Sound Area. 
Equipment representing each Agency's equipment and configuration shall be 
assembled in a single test-bed (“RFCS test-bed”) to permit interconnection to 
simulate the overall RFCS configuration and operation. The RFCS test-bed shall 
be used to perform, among other things, device testing, device interface and 
integration testing, including systems integration, and configuration data testing 
and administration. 

It is not required that the Central System or DACS which support financial and 
operational data processing be co-located at this site, but it must be possible to 
interconnect to them using the telecommunications processes to be used in the 
installed system environment._The RFCS central system (clearinghouse, servers 
and associated systems and networks) shall be connected to the test bed to 
support full operation of all systems and subsystems in the RFCS test bed. The 
RFCS testbed also includes the devices, connections and network that enable 
Washington State Ferries (WSF) to remotely access an RFCS Release in the 
testbed in order to test it in conjunction with other WSF hardware and software 
that are integrated with the RFCS. 

b. The test-bed shall be established prior to the commencement of System 
Integration Testing. Each Agency’s actual equipment shall also be utilized in the 
RFCS test-bed to perform end-to-end testing prior to delivery of said Agency 
equipment to Agency facilities. 

c. The Contractor shall be responsible for the test-bed environment until 
completion of Contract. 

The test-bed shall remain operational through the duration of the Contract and 
shall be updated to reflect any changes to the devices, software, system 
configuration and/or configuration data. 


2.0 Change to Section 6.11-11.4.7.1 

Section 6.11-11.4.7.1 is amended to read as follows: 

11.4.7.1 Acceptance Testing Settling In Period 

The initial period of time following the completion of the Phase II Milestone of 
"Completion of Complete System Commissioning" shall be designated as the 
Acceptance Testing Settling In period. The Contractor shall archive data created during 
development and testing so that the Settling-in period shall commence with clean 
databases. 

(a) The Acceptance Testing Settling In period will last for at least thirty (30) days 
prior to beginning Acceptance Testing. During the Acceptance Testing Settling In 
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period, all areas of the RFCS System will be available for the Agencies' use, 
including performing all production functionality and conducting training. 

(b) During the Acceptance Testing Settling In period a failure review test process 
shall be established (CDRL 20) by the Failure Review Team. 

(c) At the end of the Acceptance Testing Settling In period the Mean Transactions 
Between Failures (MTBF) for high transaction volume equipment of the same 
type shall be not less than 40% of the MTBFs presented in Division III for each 
type of RFCS equipment. 

(d) For equipment of the same type in a low transaction volume environment, the 
mean operating hours between failures (MOFIBF) in a group shall be not less 
than 40% of the mean hours between failures presented in Division III for each 
type of RFCS equipment. 

(e) If at the end of the Acceptance Testing Settling In period the above MTBF and 
mean operating hours between failures (MOFIBF) criteria are not met, then the 
reliability of the equipment shall be monitored until these criteria are met for thirty 
(30) consecutive days. 

(f) Acceptance testing shall not commence until the MTBF and MOFIBF 
requirements in (c) and (d) above are met. 

3.0 Contract Document Requirements List 

Section 6.11-11.6 is amended by adding the following to Figure 11-11.6, "Contract Document 
Requirements List." 

CDRL 43 Overall RFCS Release Plan 
CDRL 44 Detailed RFCS Release Plan 
4.0 New Section added to Section 6.11-11 
A new section, Section 6.11-11.7, is added as follows: 

6.11-11.7 Phase 2 Development and Testing Period 

The following provisions shall apply during the Phase 2 Development and Testing Period which 
is the period that begins with the commencement of Phase 2 and continues through the 
Milestone "Completion of Complete System Commissioning." The provisions in this Section 
11.7 shall control in the event of any conflict with other provisions in the Contract. 


11.7.1 Definitions 

a. Hardware Revisions - any changes to the design or manufacture of ERG-supplied RFCS 
hardware, including but not limited to new hardware or peripherals, new or end-of-life 
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replacement components used in existing hardware, and any hardware that has been altered 
or modified. 

b. Software Revisions - any changes to the design or coding of RFCS software or firmware, 
including but not limited to new software, software Updates, software Upgrades, or software 
changes or Modifications. 

c. Document Revisions - any changes to the content, format or presentation of a document 
whether in electronic or paper format. 

d. Phase 2 Revisions - Collectively, Hardware, Software and/or Document Revisions that will 
be provided in Phase 2 for use in Full System revenue service, including revisions listed in 
Section 2 and other revisions as may be agreed to by the Parties. 

e. RFCS Release - Collectively, Hardware, Software and/or Document Revisions that are 
grouped together for the purpose of development, testing, and release into the RFCS test and 
production environments. 

f. RTB - the Regional Testbed located in the Contractor’s Seattle facility which includes all 
equipment, software and systems necessary to conduct end-to-end testing of the RFCS, 
except for banking interfaces, ACH file submission and settling with financial institutions. The 
RTB also includes the devices, connections and network that enable Washington State Ferries 
(WSF) to remotely access an RFCS Release in the RTB in order to test it in conjunction with 
other WSF hardware and software that are integrated with the RFCS. 

g. RTB Test Period - The period of time that Agency staff have access to the RTB for the 
purpose of conducing user testing of an RFCS Release. 

h. Overall RFCS Release Plan - a document listing all Phase 2 Revisions, assigning each 
RFCS Revision to an RFCS Release, and providing a schedule of all planned RFCS Releases. 

i. Detailed RFCS Release Plan - a document issued prior to the commencement of work on a 
specific RFCS Release that lists all documents, test plans and test procedures to be utilized 
and/or revised as part of the development, testing and release of the RFCS Release, as well 
as a proposed schedule of RFCS Release and Document Revision activities (including the 
RTB Test Period agreed to for that RFCS Release). 

j. RFCS Release Notes - a document provided with each RFCS Release describing the 
release content, application notes, and release instructions. 

k. Onboard Equipment (OBE). Units of RFCS equipment installed onboard Agency coaches; 
the PFTP’s, SAFTP’s and GAK’s installed at Sound Transit and at Washington State Ferries; 
and any of the above in Test/Training Rigs as defined below. 

l. Test/Training Rigs. Units of Onboard Equipment provided to the Agencies for the purpose of 
testing/training outside of a bus or terminal. 

m. Production System. The RFCS devices and systems to be utilized for operation of the 
RFCS in Phase 2, including equipment, networks and systems installed at/to Agency premises, 
and the RFCS clearinghouse and associated services. It is recognized that financial settlement 
and funds movement will occur with use of this system. 
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11.7.2 Scope of Phase 2 (Revisions and System/Services) 

a. The Phase 2 Revisions shall consist of (a) the revisions required to resolve all Development 
Issues (DEVIs) that have been identified to date and will be subsequently identified; (b) the 
revisions needed to implement the functionality identified by the Agencies in the numbered 
Requests for Information (RFIs) that are listed in the "Phase 2 Revisions List," dated 
September 26, 2007, attached hereto as CO-26-Appendix A. (Regarding the PFTP, the 
Parties acknowledge open issues exists as to the hardware platform and agree to diligently 
proceed in good faith to decide on the hardware to be used for Phase 2 and resolve the cost 
implications, if any, by October 15, 2007. Until the hardware has been selected, the Contractor 
agrees to defer any activities on RFCS RFI 243 that would vary according to the hardware.) 
The Parties acknowledge that RFIs are exchanges of information, not agreements, change 
orders or amendments to the Contract. The purpose of listing the RFIs in CO 26-Appendix A 
is to identify the functionality that will be addressed by the Phase 2 Revisions. As provided 
below, revised design documents will be developed for the Phase 2 Revisions and, upon their 
being issued a NAC, said revised design documents will constitute Contract Documents. The 
Parties acknowledge and agree that the RFIs are not, and shall not be construed to be, 
Contract Documents or parts of the Contract. 

b. The Contractor shall provide and maintain the following systems during the Phase 2 
Development and Testing Period: 

1) The Regional Testbed 

2) The Production System 

Commencing thirty (30) days prior to the First Release being made available for user testing in 
the RTB as provided in Section 76.3.13, and thereafter for the duration of the Phase 2 
Development and Testing Period, the Agencies shall conduct testing of the RFCS through the 
Regional Testbed and/or Production System using Agency staff and designated test personnel. 
The Contractor agrees that its provision of the RTB, the Production System and the services 
described hereunder, and the Agencies access and use of same, shall not (a) trigger any 
maintenance costs or other compensation except for the lump sum provided in Section 3.1- 
76.3.12; or (b) limit, reduce or otherwise affect the Contractor's obligations under the Contract 
including but not limited to its obligations under Section 3.1-52-53 (Pre-Acceptance 
Deficiencies), Sections 3.1-55-63 (Warranties) and Section 6.11-11.4.7 (System Acceptance 
Testing). 

Throughout the duration of the Phase 2 Development and Testing Period, the Contractor shall 
provide the following services and service levels: 
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SERVICE 

AREA 

SERVICES TO BE PROVIDED 

SERVICE LEVELS 

a. Regional 

Testbed 

Operation 

The RTB shall provide all RFCS 
functionality except banking interfaces 
and ACH file submission and settling 
with financial institutions, in a test 
environment, and shall include 
equipment, services and support for 
each and all of the seven (7) RFCS 
participating Agencies. 

The RTB shall be available for Agency 
testing of RFCS Releases and Agency CD 
testing from 9:00 AM to 5:00 PM during 
normal business days and on weekends if 
necessary to test particular fare products. 
Testing time will be scheduled between the 
Agencies and ERG. ERG staff shall be 
onsite during all RTB testing to assist 

Agency staff. (The Contractor agrees that it 
will provide training courses at Agency 
facilities and not in the RTB.) 

b. Production 
System Operation 

The production system shall include all 
devices, systems and networks 
required to operate the RFCS, whether 
at Contractor or Agency facilities. The 
Disaster Recovery site will be 
maintained in operation. 

The production system shall be available 

24 hours a day seven days a week, except 
as reasonably required to accommodate 
planned maintenance periods. Such 
maintenance periods shall be coordinated 
with the Agencies. 

c. Customer 
Service 

The Contractor shall provide Help Desk 
services to answer Agency questions 
and inquiries. 

The Seattle Technical Support Help Desk 
shall be available from 9:00 AM to 5:00 PM 
during normal business days. 

d. RFCS 

Websites 

All RFCS websites (Agency Website, 
Business Account Website, Call Center 
Websites) shall be maintained in 
operation. 

All RFCS websites shall be available per 
the requirements for Production System 
Operation. 

e. Other Sales 
Channels 

All other sales and revalue channels 
(customer service terminal, terminal 
retail unit, and mail center) shall be 
maintained in operation. 

All other sales channels shall be available 
per the requirements for Production 

System Operation. 

f. Local Servers 
and Networks 

All local servers (data acquisition 
computers, back office computers, and 
related equipment), wired networks, 
and wireless networks shall be 
maintained in operation. 

All local servers and networks shall be 
available per the requirements for 

Production System Operation. 

g. Fare Card 
Procurement and 
Distribution 

At the Agencies request, the Contractor 
shall provide a one-time procurement 
and distribution of up to 1,000 fare 
cards, at a per card price of $4.89 (that 
includes any and all charges for the 
card and its initializing, distribution, 
management and other services), to be 
used for test purposes per the 
requirements of 6.11-3 of the Contract. 

Cards shall be procured and distributed 
per the requirements of 6.11-3 of the 

Contract. 

h. Fare Card 
Management 

The Contractor shall provide fare card 
management per the requirements of 
6.11-4 of the Contract as required to 
support testing. 

Management services, as required for 
testing, shall be per the applicable 
requirements of 6.11-4 of the Contract. 

i. Financial 
Management and 
Clearinghouse 

The Contractor shall provide and 
maintain all financial management and 
clearinghouse services per the 

Clearinghouse services shall be available 
per the requirements for Production 

System Operation. Financial reconciliation 
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SERVICE 

AREA 


SERVICES TO BE PROVIDED 


SERVICE LEVELS 


Services 

requirements of 6.11-5 and 6.11-6 of the 
Contract. 

The total number of cards in use during 
testing shall be less than or equal to 
1,000, except if required for system 
stress testing. 

settlement process shall be initiated, on 
average, every three (3) days, except as 
required to support specific test scenarios. 
Settlement and reconciliation timing shall 
be per Figure 8 of Section 6.4 of DR 6 
(ERG Document SEA-00033). 

j. Maintenance 
Services 

The Contractor shall provide local 
maintenance and repair of RTB and 
Production System devices used in 
testing. 

The Contractor shall be responsible for 
repair and replacement within two (2) 
business days for any malfunctioning 
device(s) that are covered by On-site 
Maintenance; and within 14 calendar days 
for any malfunctioning device(s) that are 
covered by Depot Maintenance). In the 
event that a repair cannot be completed 
within that period, the Contractor shall 
supply and install a replacement device 

k. General 

Support Services 

In addition to the Seattle Technical 
Support Help Desk, the Contractor shall 
maintain the following support services: 

A. Incident recording and 
reporting. 

B. Local field support. 

C. Network and device operation 
support. 

The following service levels shall apply: 

A. Incident recording and reporting: 

The Contractor shall hold incident 
reporting teleconferences and 
create/update incident reports in 
accordance with the Incident 

Review Process described in Sec. 
11.7.5(b). 

B. Local field support. A local 
technician shall be available to 
respond to non-emergency 
problems or issues at Agency 
facilities from 9:00 AM to 5:00 PM 
during normal business days. 
Response shall be within the next 
business day of notification. 

C. Network and device operation 
support shall be supplied via the 
Help Desk from 9:00 AM to 5:00 

PM during normal business days. 


11.7.3 Phase 2 Design 

a. For each Phase 2 Revision which contains Hardware Revisions and/or Software Revisions, 
the Contractor shall prepare Document Revisions as required, and shall submit revised design 
documents (DRs and CDRLs) and images of revised website pages for Agency review and 
issuance of a NAC. The RFCS Revision shall not be released for FAT testing until a NAC for 
the revised design documents has been received. 

b. Proposed revisions to documents shall be shown by providing the entire document with 
underlines for new content and strikethroughs for deleted content. Proposed revisions to 
website pages shall be shown by providing images of the proposed revised web pages. 
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c. Document Revisions shall be made throughout Phase 2, subject to Agency review and 
issuance of a NAC, to reflect the functionality and processes delivered in Phase 2. Phase 1 
Design documents not needing modification during Phase 2 need not be submitted, however 
with each Document Revision the Contractor shall provide an updated list of all current 
documents listing the document name, identifier, latest revision number, and latest revision 
date. 

11.7.4 RFCS Release Plans and Testing Plans/Procedures 

a. The Contractor shall submit an Overall RFCS Release Plan (CDRL 43) that lists all Phase 2 
Revisions, and assigns all such Revisions to a scheduled RFCS Release. The Contractor and 
the Agencies shall work together to agree on the assignment of Phase 2 Revisions to a RFCS 
Release, based on the ability of all Parties to support such assignments and the Parties' 
agreement that the highest priority is for the earliest release of those Phase 2 Revisions that 
affect operator training (i.e. any revisions to onboard equipment and functionality) and 
customers (i.e. any revisions to websites). Such Overall RFCS Release Plan shall be subject 
to Agency review and issuance of a NAC before testing commences on any RFCS Release. 

b. With each RFCS Release, the Contractor shall provide the Detailed RFCS Release Plan 
(CDRL 44). Such Plan shall be subject to Agency review and issuance of a NAC before 
development and testing of that RFCS Release. 

c. The Contractor shall provide Factory Acceptance Test (FAT) and Systems Integration Test 
(SIT) plans, procedures and results for each RFCS Release, subject to Agency review and 
issuance of a NAC. 

d. With each RFCS Release, the Overall and Detailed RFCS Release Plans shall be revised 
and resubmitted to the Agencies to reflect any Severity 3 or Severity 4 issues that remain 
unresolved (as provided in Section 11.7.5 below), and any new issues that have been 
identified. Such issues shall be included in a future RFCS Release and so indicated in both 
the Overall RFCS Release Plan and Detailed RFCS Release Plan(s) associated with the future 
RFCS Release(s). 

11.7.5 Development and Testing of Each RFCS Release 

a. Development . Once a NAC has been issued for a modified design document related to 
the Phase 2 Revisions in a RFCS Release, the Contractor may commence its development 
and testing activities. 

b. Issue Resolution Process and Issue Severity Classifications . 

The following is a general description of the Issue Resolution Process that will be used as 
issues are reported during the course of the Phase 2 Development and Testing Period, through 
the Milestone of "Completion of Complete System Commissioning." Another process will be 
developed for resolution of issues that arise on systems and equipment being operated in 
revenue service (post Completion of Complete System Commissioning). 

1. All issues reported by either the Contractor or the Agencies shall be entered by the 
Contractor into the Contractor's log, and assigned a tracking reference number (i.e. 
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Development Issue or DEVI number in ERG’S issue tracking system) and severity 
classification at the time of identification, according to the following four severity classifications. 


Issue Severity Classifications 


Severity 

Definition 

1 - Critical 

• Critically affects the primary business service, major 
application, or mission critical system; 

• Materially impacts the Agency’s ability to deliver transit 
service or fare collection; 

• No workaround is available; 

• Fatal error, application halt; 

• Multiple test cases aborted until defect corrected; 

• Critical path schedule impact; 

• Loss of Production Data; 

• High priority functionality critically affected; or 

• Functionality affecting customers, customer service 
representatives, coach operators, fare inspectors, or WSF 
fare collection staff is not available. 

Examples: All CSTs will not launch, Web Site Unavailable, 

2 - Important 

• The business service, major application, or system is 
seriously affected or implementation stopped; 

• The system is exposed to potential loss or interruption of 
service; 

• No acceptable workaround is available; 

• Serious error, graceful exit; 

• Core functionality or primary interface affected; 

• Test case(s) cannot continue until defect corrected or 

• Functionality affecting customers, customer service 
representatives, coach operators, fare inspectors, or WSF 
fare collection staff does not operate as designed. 

Examples: A single CST will not launch, a single Web Service is 
Unavailable, Production Backup Failure 
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Severity 

Definition 

3 - Routine 

An issue that is not a 1 or 2 Severity and meets one of the 
following criteria: 


• 

A business service, major application, or system is 
moderately impacted, no data has been lost, and the 
business service, application, or system is still functioning; 


• 

Workaround available; or 


• 

Secondary interfaces or functionality affected. 


Examples: Layout of an Agency Website navigation bar 

4 - Low 

An issue that is not a 1 or 2 Severity and meets one of the 
following criteria: 


• 

Issue or defect requires modifications to testing 
procedures, but does not materially affect test or results; 


• 

Workaround available, if required; or 


• 

Low visibility error or no functionality impact. 


Examples: Spelling Errors, Minor Documentation Errors (typos), 
Sort Order, colors 


2. If the Agencies identify an issue, they shall inform the Agencies' Contract Administrator 
(C.A.), or designee, who will be responsible for sending, via email, an issue report to the 
Contractor's Project Manager (P.M.), or designee. The issue report shall describe the nature of 
the problem, any investigative or other actions taken prior to the report, any results of such 
actions, and the Agencies' classification of the issue as Severity 1, 2, 3 or 4. The Contractor 
shall acknowledge receipt of any Agency-reported issues by assigning it a tracking reference 
number, and emailing that number back to the Agencies' C.A. or designee along with 
confirmation of, or proposed changes to, the initial severity classification. 

3. If the Contractor identifies an issue, it shall assign the issue a tracking reference number 
and email a report to the Agencies' C.A. or designee that includes the tracking number, the 
nature of the problem and an initial severity classification as proposed by the Contractor. The 
Agencies C.A. or designee will confirm receipt of the issue report, and confirm or identify 
proposed changes to, the initial severity classification. 

4. The Contractor shall review all issues, diagnose the cause of the issue and identify potential 
resolution approaches. In the event that the Contractor believes that additional investigation is 
required to confirm a reported issue, the Contractor shall so indicate in its acknowledgement of 
the issue, and shall also identify any recommended follow-up actions to be taken by the 
Contractor and/or Agencies. The issue shall be maintained and tracked based on the initial 
issue report, however its status and severity rating may be subsequently revised by mutual 
agreement based on the results of any additional investigation. A reported issue may be closed 
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if neither the Agencies nor the Contractor can reproduce the issue within a reasonable 
timeframe, in which case the closure shall be recorded as "issue not able to be reproduced. 


5. The Contractor shall submit to the Agencies a weekly Test Status Report on the status of all 
testing and issues as recorded in the Contractor’s issues log. 

6. Unless otherwise agreed, the parties shall hold daily meetings during user testing in the 
RTB, and twice weekly during user testing on Agency production equipment, to discuss the 
status of the issues, closure requests, proposed revisions to severity ratings, technical 
questions or clarifications, and the Contractor's diagnosis and proposed approach(es) to 
resolution. For any technical issue discussions, the Contractor and Agencies shall provide 
personnel who are qualified to discuss the issue, investigation results and potential 
approaches to resolution. 

7. The meetings will occur by teleconference, with the Contractor providing the teleconference 
service and the Agencies reimbursing the Contractor the lesser of one-half the actual monthly 
charge for calls made for these meetings or $5,000 per month. The Contractor shall provide 
the Agencies with documentation of the actual charges for these calls. Provided, however, the 
Agencies reserve the right to terminate this reimbursement with thirty (30) days written notice 
save that the Agencies will share the charges for calls made for these meetings prior to such 
notice in accordance with this paragraph 7. In such event, the daily meetings shall occur at 
King Street Center and the Contractor and the Agencies shall be responsible for their own 
costs in providing the telephone connection, if any, for their required personnel to participate. 


c. HFAT. The Contractor shall submit Hardware Factory Acceptance Test (HFAT) plans, 
procedures and results for all Hardware Revisions. For all new hardware devices or 
peripherals, new HFAT plans, procedures and results shall be supplied. For any Phase 1 
hardware that has been modified or has had components changed due to end-of-life or other 
reasons, the Contractor shall resubmit updated versions of the Phase 1 HFAT plans, 
procedures and results providing evidence that the hardware in its revised configuration has 
passed all applicable tests. The Agencies, at their sole discretion and expense, may witness 
the HFAT tests as scheduled by the Contractor. 

All Hardware Revisions included in an RFCS Release must pass HFAT before the RFCS 
Release proceeds to SIT. Hardware Revisions associated with an RFCS Release shall be 
considered to have “passed” HFAT if: 

1) all the Hardware Revisions in the RFCS Release have been tested; and 

2) any hardware-related Severity 1 or 2 issues identified in testing have been fixed, 
tested and passed; and 

3) Seventy-five percent (75%) of the combined hardware-related Severity 3 and 4 
issues identified in testing have been fixed, tested and passed. 

When the Contractor believes that a RFCS Release containing Hardware Revisions has 
passed HFAT, the Contractor shall submit an HFAT Report (CDRL 24A) to the Agencies that 
lists the results of each test of each Hardware Revision. Each HFAT Report shall be subject 
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to Agency review and issuance of a NAC. Except for the final RFCS Release, outstanding 
hardware-related Severity 3 and 4 issues within the 25% maximum shall be added to a 
subsequent RFCS Release related to hardware, and both the Overall and Detailed RFCS 
Release Plans shall be revised in accordance with Section 6.4 above. The final RFCS 
Release related to hardware shall not be considered to have “passed” FI-FAT if any Severity 3 
or 4 issues related to hardware remain unfixed, unless the Agencies, in their sole discretion, 
agree in writing via their Contract Administrator that such issues may be deferred to be fixed 
during SIT. 

d. FFAT . The Contractor shall submit Functional Factory Acceptance Test (FFAT) plans, 
procedures and results for all Software Revisions. The Agencies, at their sole discretion and 
expense, may witness the FFAT tests as scheduled by the Contractor. 

All Software Revisions included in an RFCS Release must pass FFAT before the RFCS 
Release proceeds to SIT. Software Revisions associated with an RFCS Release shall be 
considered to have “passed” FFAT if: 

1) all the Software Revisions in the RFCS Release have been tested; and 

2) any software-related Severity 1 or 2 issues identified in testing have been fixed, 
retested and passed unless the Agencies, in their sole discretion, agree in writing via 
their Contract Administrator that the issues may be deferred to another RFCS Release; 
and 

3) Seventy-five percent (75%) of the combined software-related Severity 3 and 4 issues 
identified in testing have been fixed, retested and passed. 

When the Contractor believes that a RFCS Release containing Software Revisions has passed 
FFAT, the Contractor shall submit an FFAT Report (CDRL 24B) to the Agencies that lists the 
results of each test of each Software Revision. Each FFAT Report shall be subject to Agency 
review and issuance of a NAC. 

Outstanding software-related Severity 3 and 4 issues within the 25% maximum shall be added 
to a subsequent RFCS Release, and both the Overall and Detailed RFCS Release Plans shall 
be revised in accordance with Section 6.4 above. The final RFCS Release shall be considered 
to have “passed” FFAT if a maximum of 25% of the combined Severity 3 and 4 issues remain 
unfixed, save that any such issues shall be fixed prior to Full System Acceptance. . 

e. SJT. After passing HFAT and/or FFAT (as required for the specific RFCS Release), the 
RFCS Release shall be subjected to System Integration Testing (SIT) in the Contractor’s 
facility, according to the NAC’d test plan and test procedures for that RFCS Release. The test 
procedures shall include: testing of the Revisions in a RFCS Release; “touch point” testing of 
the other elements and functions of the RFCS that are related to, and reasonably likely to be 
affected by, the Revisions in that RFCS Release; and a standard set of tests to be conducted 
for each RFCS Release that demonstrate end-to-end functionality. The Agencies, at their sole 
discretion and expense, may witness the SIT tests as scheduled by the Contractor. 

Each RFCS Release must pass SIT before it may proceed to the RTB. A RFCS Release shall 
be considered to have “passed” SIT if: 

1) all the Revisions in the RFCS Release have been tested; 
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2) any Severity 1 or 2 issues related to hardware identified in testing have been fixed, 
tested and passed; 

3) any Severity 1 or 2 issues related to software identified in testing have been fixed, 
tested and passed unless the Agencies, in their sole discretion, agree in writing via their 
Contract Administrator that the issues may be deferred to another RFCS Release; and 

4) seventy-five (75%) of the combined Severity 3 and 4 issues identified in testing have 
been fixed, retested and passed. 

When the Contractor believes that a RFCS Release has passed SIT, the Contractor shall 
submit a SIT Report (CDRL 24C) to the Agencies that lists the results of: each test of each 
Revision; all “touch point” testing; and the standard tests. Each SIT Report shall be subject to 
Agency review and issuance of a NAC according to the Review Process in Section 3 above. 
Except for the final RFCS Release, outstanding Severity 3 and 4 issues within the 25% 
maximum shall be added to a subsequent RFCS Release and both the Overall and Detailed 
RFCS Release Plans shall be revised in accordance with Section 6.4 above. The final RFCS 
Release shall be considered to have “passed” SIT if a maximum of 25% of the combined 
Severity 3 and 4 issues remain unfixed save that those issues shall be fixed prior to Full 
System Acceptance. 

f. RTB User Testing . After passing SIT, each RFCS Release shall be installed by the 
Contractor in the Regional Testbed (RTB) at its Seattle facility to enable the Agencies to 
commence user testing. Prior to notifying the Agencies in writing that the RTB is ready for 
them to commence user testing, the Contractor shall conduct that part of installation testing, 
network connectivity testing, testing of updated Configuration Data (CD), functional testing, 
and any other testing necessary to verify the RTB is ready for user testing. 

After receiving said notification, the Agencies shall have a mutually agreeable number of 
business days, which shall not be less than ten (10) business days but not more than twenty 
(20) business days, for scheduled conducting of the user testing in the RTB. The number of 
business days scheduled for user testing shall be specified in the NAC'd Detailed RFCS 
Release Plan and shall include the number of business days reasonably necessary for 
Agencies to test each RFCS Release, given the number and nature of Phase 2 Revisions 
proposed for inclusion therein. 

The scheduled period specified in the agreed Detailed Release Plan shall be extended as 
required in order to re-conduct or restart failed or suspended tests as defined below under test 
“stop-start criteria”, and/or to reasonably provide the Agencies with sufficient time to test any 
and all revisions associated with the release, as well as conduct end-to-end testing of the 
system through a series of standard tests (regression tests). 

The Contractor shall provide support during the RTB user testing by assigning to the RTB such 
Contractor employees that are knowledgeable about the RTB and the specific RFCS Release 
being tested as necessary. In order for the Contractor to be able to provide such testing 
support, the Agencies shall provide a copy of their RTB User Testing plan to the Contractor at 
least ten (10) business days prior to the scheduled start of RTB testing. 

User testing in the RTB detailed in the RTB testing plan may include, but is not limited to, 
repeating all or some of the SIT test procedures (including “touch point” testing and the 
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standard tests) and other tests of the RFCS Release. The Agencies will inform the Contractor 
of issues in accordance with the Incident Review Process specified in Section 6.11-11.7.5(b) 
above. 

Each RFCS Release must pass User Testing in the RTB before it may proceed to the 
Production System. A RFCS Release shall be considered to have “passed” RTB if: 

1) all the Revisions in the RFCS Release have been tested; 

2) any Severity 1 or 2 issues related to hardware identified in testing have been fixed, 
retested and passed; 

3) any Severity 1 or 2 issues related to software identified in testing have been fixed, 
retested and passed unless the Agencies, in their sole discretion, agree in writing via 
their Contract Administrator that the issues may be deferred to another RFCS Release; 
and 

4) Seventy-five (75%) of the combined Severity 3 and 4 issues identified in testing have 
been fixed, retested and passed. 

Outstanding Severity 3 and 4 issues within the 25% maximum shall be added to a subsequent 
RFCS Release and both the Overall and Detailed RFCS Release Plans shall be revised in 
accordance with Section 6.4 above. The final RFCS Release shall be considered to have 
“passed” RTB User Testing if a maximum of 25% of the combined Severity 3 and 4 issues 
remain unfixed, save that such issues shall be fixed prior to Full System Acceptance.. 

g. Test Stop-Start Criteria. All tests shall be subject to suspension and resumption of the test 
period duration, as follows: 

1) In the event that a Severity 1 or 2 issue is encountered that results in the interruption 
of a test procedure, the test procedure shall be suspended until the issue has been 
rectified. The test procedure shall resume upon rectification of the issue. The testing 
period specified in the agreed Detailed Release Plan shall be extended to allow 
completion of the test procedure as planned. 

2) In the event that the Agencies are unable to execute a test procedure in RTB testing 
due to planned functionality being unavailable or problems with the system, the RTB 
test period specified in the agreed Detailed Release Plan shall be extended until the 
functionality is made available or problems rectified, and the test procedure executed as 
planned. 

3) The above conditions do not apply to those Severity 3 and 4 defects that the parties 
have mutually agreed can be moved to a subsequent RFCS Release. 

h. User Testing on Agency Production Equipment . Upon satisfactory completion of RTB 
testing of each RFCS Release, the RFCS Release will be released into the Agencies’ 
production equipment via the network. The Contractor shall coordinate with the Agencies on 
the schedule of any RFCS Releases into the Agencies' production equipment, and shall 
provide a complete set of RFCS Release Notes with each such RFCS Release. 
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In the event that the release of the software into the Agency production equipment creates a 
Severity 1 or 2 issue, the Contractor shall roll-back the RFCS Release to the prior version, and 
shall undertake such corrective action as needed to resolve Severity 1 or 2 issues identified. 

The Agencies may continue testing each RFCS Release on installed production equipment 
and test rigs at Agency facilities except that Contractor shall give the Agencies reasonable 
notice, in accordance with Section 11.7.2(b) above, of any period when the system is 
unavailable. Agencies shall identify issues and the Contractor shall resolve such issues in 
accordance with the Incident Review Process specified in Section 6.11-11.7.5(b) above. 

Should the resolution of an issue require a further Phase 2 Revision, such Phase 2 Revisions 
shall be described and included in a revision to the Overall and Detailed RFCS Release Plans. 

The Agencies acknowledge that such RFCS Release may not represent the final Phase 2 
software, and will make reasonable accommodations to support additional testing and 
maintenance that the Contractor may wish to undertake. 

The final RFCS Release must have been tested in the Agency environment for thirty (30) 
calendar days and all identified issues in all RFCS Releases shall have been closed with 
Agency agreement before the Completion of Complete System Commissioning Milestone may 
be NAC'd. 

i. System Live . To enable the user testing using the RTB and the Agency production 
equipment, the Contractor and the Agencies have agreed that the RFCS shall remain “live” 
and accessible via the RTB and the Agency production equipment, and be supported by the 
Contractor, all in accordance with Section 11.7.2(b) above. These facilities, systems and 
services are considered to be in addition to, and not in lieu of, the maintenance, support and 
other obligations of the Contractor under the Contract. Additional compensation is provided in 
accordance with Section 3.1-76.3.13. 

j. Final “As built” Design Documents. Upon satisfactory completion of Phase 2 System 
Development, RFCS Release and Testing, all Phase 2 Final Design Review Documents shall 
be revised/updated with any changes that resulted from the development and testing process. 
Once NAC’d, revisions to a document will be submitted as a "Change Request" for written 
approval by the Agencies' Contract Administrator in accordance with RFCS change 
management process. 

Any documents that are unchanged as a result of Phase 2 activities shall be so noted, and the 
most recent version designated as the final as-built document. 

In any event, the Contractor shall provide a comprehensive list of the final “as-built” versions of 
all documentation, listing the document name, ERG reference number, most recent revision 
date, and revision number. 

k. Plardware Commissioning and Complete System Commissioning . 

l. The Contractor has been performing hardware commissioning on a device-by-device basis 
as it is installed at Agency facilities and on Agency vehicles. Completion of all such device 
commissioning, however, does not constitute "Completion of Complete System 
Commissioning." As agreed in Section 3 below, achieving said Milestone requires among 
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other Contract obligations, that all RFCS devices that have been individually commissioned 
are fully operational. To the extent that such equipment has been disconnected from power 
after individual device commissioning, it will need to be "powered-up" and successfully loaded 
with the RFCS software that incorporates the applicable Phase 2 Revisions. 

The following activities shall be performed on days and at times agreed upon by the Parties in 
coordination with the training of an Agency's employees. 

(a) The Agencies will re-connect power to previously commissioned devices. The 
Contractor will provide field support at Agency facilities as necessary to assist the 
Agencies with any problems that arise during this activity. 

(b) The Contractor is responsible for ensuring that the final Phase 2 version of RFCS 
software is automatically downloaded as the devices are powered-up. The Contractor 
will provide field support at Agency facilities as necessary to ensure this download is 
successful. 

(c) Because KCM’s essential radio functionality is dependent on a successful download 
to the on-board equipment (OBE), the Contractor shall take the following additional 
actions to support KCM's re-connecting of power to the OBFTP and the downloading of 
the final Phase 2 RFCS software to KCM's OBE. Prior to commencing the above re¬ 
powering and downloading activities for the entire KCM fleet, the Contractor and KCM 
will conduct a pilot test of ten buses on a Sunday to identify and resolve issues. 
Thereafter, the Contractor will assign a knowledgeable person to be present at KCM 
facilities to troubleshoot and support the activity of reconnecting power and downloading 
the final RFCS software to the OBE. 

2. As provided in Section 6.11-11.4.5(a), the Contractor shall submit a Plan for Complete 
System Commissioning to "demonstrate that all systems are fully operational prior to entering 
revenue service." As provided in Section 6.11-11.4.5(b), said Plan for Complete System 
Commissioning shall: 

...identify and describe all necessary tests to verify proper interfacing and installation of 
the equipment with other system facilities, including at a minimum: 

i. Schedule for system commissioning. 

ii. Commissioning test period. 

iii. Procedures for collecting and verifying data from each type of equipment. 

iv. Procedures for verifying the correct transfer of control commands to each 
type of equipment. 

v. Test reports content to be prepared. 

3. The Milestone for "Completion of Complete System Commissioning" shall be deemed 
satisfied and eligible to be NAC'd upon the Contractor demonstrating that the following 
requirements have been met: 
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(a) all Phase 2 Revisions have been successfully completed and tested as provided 
above; 

(b) all RFCS devices have been individually commissioned and are fully operational and 
in-service except for any devices that are not operational or in-service due to a cause 
specified in Section 3.1-53.3; and 

(c) the Complete System Commissioning Test has been successfully completed and all 
requirements of 6.111-11.4.5 have been satisfied. 


5.0 New section added to Section 6.11-12 

A new section, Section 6.11-12.6, is added as follows: 

6.11-12.6 Phase 2 Training 

12.6.1 All Phase 2 Manuals (CDRL 34, 35), Training Materials (CDRL 29) and the 
Training Plan (CDRL 28) shall be revised to comply with the Contract requirements, the 
provisions of the Beta Readiness Waiver Agreement, and to reflect any Phase 2 Revisions. 
Said documents shall be subject to Agency review and issuance of a NAC as provided in 
Contract Section 3.1-27.5 (Phase 2). 

12.6.2 The revised Training Plan shall be delivered with the Overall RFCS Release 
Plan. 

12.6.3 The revised Manuals and Training materials shall be delivered to the Agencies at such 
time as any related RFCS Release is released into the RTB and will be used by the Agencies 
in the user testing, unless the Parties agree in the NAC'd Overall RFCS Release Plan that 
such Manuals and Training Materials may be delivered with a subsequent related RFCS 
Release into the RTB. 

12.6.4 Whether before or after a NAC is issued for the Training Plan, Manuals and Training 
Materials, the Contractor shall modify said Deliverables as necessary to reflect results of user 
testing, correction of errors or inconsistencies, and to reflect further Phase 2 Revisions that 
arise to address issues identified. Once NAC’d, revisions to a document will be submitted as a 
"Change Request" for written approval by the Agencies' Contract Administrator in accordance 
with RFCS change management process. 

END 
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